Security Recommendations
The Temenos Digital solution comes with an in-built enterprise grade security features expected for apps in the banking domain.
Capabilities
Temenos has built several capabilities in the banking application, such as:
- Fingerprint authentication for iOS (phone and tablet) and Android (phone only) devices.
- Masking
- Passwords and credit/debit card numbers are always masked wherever displayed.
- Account numbers are masked in the application and only the last four digits are displayed.
- Sensitive data exposure
What is it? Many web applications do not properly protect sensitive data, such as payment card data, personally identifiable information, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
How is it addressed? Temenos platforms use FIPS 140-2 validated cryptographic modules. Sensitive data is not stored unnecessarily. Sensitive is encrypted both are rest and transit. Temenos has implemented a combination of asymmetric cryptography and symmetric cryptography practices, including White-Box Cryptography (WBC) in our products to protect keys, and other sensitive information with the strongest security measures.
- How is it addressed in Retail Banking product?
- The data stored in the device is encrypted. The user ID encrypted at rest and in transit. Even if a “Remember Me” feature is created, the user ID can be masked when retrieved.
- Client uses AES 256 encryption to store the password.
- Application related information such as account statement, card images, check images for Mobile Deposit or Pay Bill functions are never stored. The images are deleted from temporary memory after the user moves out of the module/flow.
- No information is logged at the client side. While generating the installer, the build is done in release mode and all the log statements are removed. Therefore, application related information is not available at the client side.
- At Quantum Fabric level, in all the pre and post processors, logging capability is implemented with multiple levels of verbosity, but no sensitive information will be logged to the log files. This information is used for debugging, and troubleshooting should the need arise.
- The application clears sensitive data (for example, password, account number, and SSN) after navigating away from the forms.
- Service calls
- Service calls use a secure channel.
- Sign out
- On sign out (either manually triggered or when the session times out), all the global information related to the user at client side is cleared.
- On sign out (either manually triggered or when the session times out), the session at middleware is invalidated, and a new session is created to log on.
- Application status cleared after logout
- On logout, all the global information related to the user at client side is cleared.
- On logout, the session at Quantum Fabric is invalidated, and a new session is created on login. After a defined idle time out, the user is logged out of the application.
- The password is encrypted while submitting over network through HTTPS.
- The solution is built using Temenos platform and therefore, the following additional security features are available:
- Hardened against hacking attacks and malware exploits.
- Encrypted at REST, in transit, and in memory.
- Session timeouts and device blocking.
- Security features across data storage, data transport, authentication, and access control.
- Exclusive one-click binary protection, that makes the application truly secure.
Recommended Security Practices
The following are the security practices to be followed by Banks/Credit unions.
Infrastructure related
- There needs to be a limit on number of re-negotiations between the client, and server or SSL or TLS session renegotiation needs to be disabled. Since the computational effort for the server far exceeds that of the client, a malicious client performing a significant number of re-negotiations may cause a DoS (Denial-of-Service) condition at the server.
- Banner information should be removed from network applications or modified to obscure the technology where possible. Some network-based applications provide information pertaining to their name, and version upon connection to the service. This can help an attacker to understand the technologies present on a target server, and target particular exploits, thereby increasing the chance of a successful compromise.
- Disable the TRACK, and TRACE methods on the web server. TRACE, and TRACK are HTTP methods that are used to debug web server connections. Servers supporting the methods are subject to cross-site-scripting attacks.
- Best Practices for configuring for web server TLS configurations.
- The remote host supports the use of SSL ciphers that offer medium strength encryption. Nessus regards medium strength as any encryption that uses key lengths at least 64-bits, and less than 112-bits, or else that uses the 3DES encryption suite. It is considerably easier to circumvent medium strength encryption if the attacker is on the same physical network.
- The SSL service supported CBC ciphers that are known to be vulnerable to cryptographic timing attacks. Known as Lucky Thirteen, timing side-channel attacks against the MAC checks of TLS may be used to break the TLS algorithm (like that of the POODLE attack).
Application related
- Secure flag should be set on all cookies that are used for transmitting sensitive data while accessing content over HTTPS. If the secure flag is set on a cookie, browsers will not submit the cookie in any request that use an encrypted HTTP connection, thereby preventing the cookie from trivially intercepted by an attacker monitoring network traffic. If the secure flag is not set, the cookie will be transmitted in clear-text format, when a user visits any HTTP URLs within the cookie's scope. An attacker may be able to induce this event by feeding a user suitable links, either directly or via another web site. Even if the domain that issued the cookie does not host any content accessed over HTTP, an attacker may use links of the form to perform the same attack.
- Set HttpOnly Flag on all cookies that do not need to be accessed by client-side scripting languages. If the HttpOnly attribute is set on a cookie, the cookie's value cannot be read or set by client-side JavaScript. This measure can prevent certain client-side attacks such as cross-site scripting from trivially capturing the cookie's value through an injected script.
- The application should return caching directives instructing browsers to not store local copies of any sensitive data. Unless directed otherwise, browsers may store a local cached copy of content received from web servers. For some browsers, including Internet Explorer, the cache content is accessed through HTTPS. If sensitive information in application responses is stored in the local cache, this data may be retrieved by other users who have access to the same system in future. We recommend setting no-cache for Cache in HTTP Response header. Therefore, no user content is stored in the browsers.
- Adherence to Password rules and policies: The following are the standard password policies must be adhered by partners and banks integrating a third-party as their authentication solution to meet PCIDSS compliance standards.
- Lockout - You can set the maximum number of failed attempts before a user account is locked out for a specified number of minutes. Here, based on the default values, a user is locked out if they enter an incorrect password 6 times.
- Lockout Duration - The duration of the login lockout. The default value is 30 minutes or until the administrator releases the user ID.
- Password Length - The minimum number of characters required for a password. The default value is 8 characters. It must contain alpha and numeric characters.
- Password Age - The password should be changed regularly. The frequency should be specified.
- Password History - Number of unique passwords that must be used before an user can re-use his old password. Configure password history length to restrict users from reusing their last 4 passwords.
- Session idle timeout - By default, sessions timeout after 15 minutes of inactivity.
Points to be noted
- Quantum Fabric has XSSFilter configured by default for the Web Apps. You do not need X-XSS-Protection header separately. The X-XSS-Protection Header is a secure header directive that instructs the user agent to enable the reflective cross site scripting filter. The X-XSS-Protection Header is designed to help and mitigate reflected cross site scripting (XSS) attacks.
- Lack of access controls and user authorization in the back-end system of the bank/CU may allow a user to get unauthorized access to another user's account data. The architecture and the appropriate solution to handle this scenario needs to be discussed during the implementation phase.
References
Quantum Visualizer Enterprise
Refer to Applying Application Security for more information on application security.
Quantum Fabric
Refer to Quantum Fabric Deployment Guide for more information on security hardening.
Installer Guides
Refer to the following Quantum Fabric Installer Guides for configuring the security settings during environment setup:
In this topic